[Chapter 11] 11.7 Troubleshooting nslookup Problems
Author: Cricket Liu & Paul Albitz
Date: 1999-01-06T18:37:45Z

#

| Chapter 11 nslookup |

## 11.7 Troubleshooting nslookup Problems

The last thing you want is to have problems with your troubleshooting tool. Unfortunately, some types of failures render the troubleshooting tool mostly useless. Other types of `nslookup` failures are, at best, confusing because they don't give you any direct information to work with. While there may be a few problems with `nslookup` itself, most of the problems you encounter will be with name server configuration and operation. We'll cover a few odd problems here.

### 11.7.1 Looking Up the Right Data

This isn't really a problem, per se, but it can be awfully confusing. If you use `nslookup` to look up a type of data for a domain name, and the domain name exists, but no data of the type you're looking for exists, you'll get an error like this:

>     % nslookup
>     Default Server:  terminator.movie.edu
>     Address:  0.0.0.0

>     > movie.edu.

>     *** No address (A) records available for movie.edu.

So what types of records do exist? Just `set type=any` to find out:

>     > set type=any
>     > movie.edu.
>     Server:  terminator.movie.edu
>     Address:  0.0.0.0

>     movie.edu
>           origin = terminator.movie.edu
>           mail addr = al.robocop.movie.edu
>           serial = 42
>           refresh = 10800 (3H)
>           retry   = 3600 (1H)
>           expire  = 604800 (7D)
>           minimum ttl = 86400 (1D)
>     movie.edu    nameserver = terminator.movie.edu
>     movie.edu    nameserver = wormhole.movie.edu
>     movie.edu    nameserver = zardoz.movie.edu
>     movie.edu    preference = 10, mail exchanger = postmanrings2x.movie.edu
>     postmanrings2x.movie.edu        internet address = 192.249.249.66

### 11.7.2 No Response from Server

What could have gone wrong if your server can't look up its own name?

>     % nslookup
>     Default Server:  terminator.movie.edu
>     Address:  0.0.0.0

>     > terminator
>     Server:  terminator.movie.edu
>     Address:  0.0.0.0

>     *** terminator.movie.edu can't find terminator: No response from server

The "no response from server" error message means exactly that: the name server didn't get back a response. `nslookup` doesn't necessarily look up anything when it starts up. If you see that the address of your server is 0.0.0.0, `nslookup` grabbed the system's host name (what the `hostname` command returns) for the server field and gave you its prompt. It is only when you try to look up something that you find out that there is no server responding. In this case, it is pretty obvious that there is no name server running - a name server ought to be able to look up its own name. If you are looking up some remote information, though, the name server could fail to respond because it is still trying to look up the item and `nslookup` gave up waiting. How can you tell the difference between a name server that isn't running and a name server that is running but didn't respond? Use the `ls` command to point out the difference:

>     % nslookup
>     Default Server:  terminator.movie.edu
>     Address:  0.0.0.0

>     > ls foo.     - Try to list a nonexistent domain
>     *** Can't list domain foo.: No response from server

In this case, no name server is running. If the host couldn't be reached, the error would be "timed out." If a name server is running, you'll see the following error message:

>     % nslookup
>     Default Server:  terminator.movie.edu
>     Address:  0.0.0.0

>     > ls foo.
>     [terminator.movie.edu]
>     *** Can't list domain foo.: No information

That is, unless there's a top-level foo domain in your world.

### 11.7.3 No PTR Data for Name Server's Address

Here is one of the most annoying problems: something went wrong, and `nslookup` exited on startup:

>     % nslookup

>     *** Can't find server name for address 192.249.249.3: Non-existent host/domain
>     *** Default servers are not available

The "nonexistent domain" means that the name 3.249.249.192.in-addr.arpa doesn't exist. In other words, `nslookup` couldn't find the name for 192.249.249.3, its name server host. But didn't we just say that `nslookup` doesn't look up anything when it starts up? In the configuration presented before, `nslookup` didn't look up anything, but that's not a rule. If you create a resolv.conf that includes nameserver lines, `nslookup` looks up the address in order to get the name server's name. In the preceding example, there is a name server running on 192.249.249.3, but it said there is no PTR data for the address 192.249.249.3. Obviously, this name server's data is messed up, at least for the 249.249.192.in-addr.arpa zone.

The "default servers are not available" message in the example is misleading. After all, there is a name server there to say the address doesn't exist. More often, you'll see the error "no response from server" if the name server isn't running on the host or the host can't be reached. Only then does the "default servers are not available" message makes sense.

### 11.7.4 Query Refused

Refused queries can cause problems at startup, and they can cause lookup failures during a session. Here's what it looks like when `nslookup` exits on startup because of a refused query:

>     % nslookup
>     *** Can't find server name for address 192.249.249.3: Query refused
>     *** Default servers are not available
>     %

This one has two possible causes. Either your name server does not support inverse queries (older `nslookup`s only), or zone security is stopping the lookup.

Old versions of `nslookup` (pre-4.8.3) used an inverse query on startup. Inverse queries were never widely used - `nslookup` was one of the few applications that did use them. At 4.9.3, support for inverse queries was dropped, which broke old `nslookup`s. To accommodate these old clients, a configuration file statement was added.

In BIND 4, the statement looks like this:

>     options fake-iquery

In BIND 8, the statement looks like this:

>     options { fake-iquery yes; };

This statement causes your name server to respond to the inverse query with a "fake" response that is good enough for `nslookup` to continue.

Zone security features can also cause `nslookup` startup problems. When `nslookup` attempts to find the name of its server (using a PTR query, not an inverse query), the query can be refused. If you think the problem is zone security, make sure your BIND 4 secure_zone TXT resource records or BIND 8 allow-transfer substatement include the network for the host running `nslookup`, and the address 127.0.0.1 if `nslookup` is running on the host also running the name server.

Zone security is not limited to causing `nslookup` to fail to start up. It can also cause lookups and zone transfers to fail in the middle of a session when you point `nslookup` to a remote name server. This is what you will see:

>     % nslookup
>     Default Server:  hp.com
>     Address:  15.255.152.4

>     > server terminator.movie.edu
>     Default Server:  terminator.movie.edu
>     Address:  192.249.249.3

>     > carrie.movie.edu.
>     Server:  terminator.movie.edu
>     Address:  192.249.249.3

>     *** terminator.movie.edu can't find carrie.movie.edu.: Query refused

>     > ls movie.edu                    - This attempts a zone transfer
>     [terminator.movie.edu]
>     *** Can't list domain movie.edu: Query refused
>     >

### 11.7.5 First resolv.conf Name Server Not Responding

Here is another twist on the last problem:

>     % nslookup

>     *** Can't find server name for address 192.249.249.3: No response from server
>     Default Server:  wormhole.movie.edu
>     Address:  192.249.249.1

This time the first nameserver in resolv.conf did not respond. We had put a second nameserver line in resolv.conf, and the second server did respond. From now on, `nslookup` will send queries only to wormhole; it won't try the name server at 192.249.249.3 again.

### 11.7.6 Finding Out What Is Being Looked Up

We've been waving our hands in the last examples, saying that `nslookup` was looking up the name server's address, but we didn't prove it. Here is our proof. This time, when we started up `nslookup` we turned on d2 debugging from the command line. This causes `nslookup` to print out the query packets it sent, as well as printing out when the query timed out and was retransmitted:

>     % nslookup -d2
>     ------------
>     SendRequest(), len 44
>         HEADER:
>             opcode = QUERY, id = 1, rcode = NOERROR
>             header flags:  query, want recursion
>             questions = 1,  answers = 0,  authority records = 0,
>             additional = 0

>         QUESTIONS:
>             3.249.249.192.in-addr.arpa, type = PTR, class = IN

>     ------------
>     timeout (5 secs)
>     timeout (10 secs)
>     timeout (20 secs)
>     timeout (40 secs)
>     SendRequest failed

>     *** Can't find server name for address 192.249.249.3: No response from server
>     *** Default servers are not available

As you can see by the timeouts, it took 75 seconds for `nslookup` to give up. Without the debugging output, you won't see anything printed to your screen for 75 seconds; it'll look as if `nslookup` has hung.

### 11.7.7 Unspecified Error

You can run into a rather unsettling problem called "unspecified error." We have an example of this error here. We've only included the tail end of the output, since we only want to talk about the error at this point. You'll find the whole `nslookup` session that produced this segment in Chapter 13, Troubleshooting DNS and BIND.

>     Authoritative answers can be found from:
>     (root)  nameserver = NS.NIC.DDN.MIL
>     (root)  nameserver = B.ROOT-SERVERS.NET
>     (root)  nameserver = E.ROOT-SERVERS.NET
>     (root)  nameserver = D.ROOT-SERVERS.NET
>     (root)  nameserver = F.ROOT-SERVERS.NET
>     (root)  nameserver = C.ROOT-SERVERS.NET
>     (root)  nameserver =
>     *** Error: record size incorrect (1050690 != 65519)

>     *** relay.hp.com can't find .: Unspecified error

What happened here is that there was too much data to fit into a UDP datagram. The name server stopped filling in the response when it ran out of room. The name server didn't set the truncation bit in the response packet, or `nslookup` would have retried the query over a TCP connection; the name server must have decided that enough of the "important" information fit. You won't see this kind of error very often. You'll see it if you create too many NS records for a domain, so don't create too many. (Advice like this makes you wonder why you bought this book, right?) How many is too many depends upon how well the names can be "compressed" in the packet, which, in turn, depends upon how many name servers share the same domain in their domain name. The root name servers were renamed to all be in the root-servers.net domain for this very reason - more names fit in DNS packets if they share a common domain, which allows more root name servers to support the Internet. As a rule of thumb, don't go over 10 NS records. As for what caused this error, you'll have to read Chapter 13. Those of you who just read Chapter 9, Parenting, may know already.

11.6 Less Common Tasks |  | 11.8 Best of the Net